[Previous] [Next] [Index] [Thread]

Re: Java "security holes'

Marianne at JavaSoft:

> The hard part is the policy, that is, once you have an applet that you
> *know* comes from Walmart, so what?

Exactly!  The hard part is the security policy, or rather the
security model that allows various policies to be implemented.

One of the current weakness in Java, from a security point of
view, is that there's no obvious security model (as smarter
folks that I have pointed out).  There are various security
features, but it's not clear that they're based on any
consistent model.  This isn't unusual!     Security is
always an unwelcome guest in the first place, and the
usual progression is <no security>, <some adhoc security
features slapped on to fix obvious holes>, <an informal
security model>, <a formal security model>.  The Java
folks deserve praise for having skipped the first phase!  *8)

I think it would be *greatly* beneficial if someone in
Java land were to put together a proposed security model,
outlining all the security-relevant things in the system,
make sure that there's some hope of getting it implemented
if it turns out to be correct, and then let it circulate
on the Net for comments.  You'd eventually end up with a
good vetted security model that you could implement.

A security model for Java would consist of, roughly:

  - A list of security-relevant entities:
    - Applets
    - Apps
    - Hosts
    - System Resources (filesystem, ports, DNS, etc)
    - and so on

  - A list of the security-relevant attributes of each:
    - The source from which an applet came,
    - Whether or not an applet is signed, and by whom,
    - The Access Control List or equivalent associated
      with each resource,
    - The trust level or whatever associated with each
      host,
    - and so on

  - A list of the various actions that the various entities
    can attempt to take,

  - A list of the security "knobs" in the system that can
    be twiddled, and by whom they can be twiddled.  (In
    general, sysadmins are going to want to be able to
    set upper limits on how much a user can decrease the
    security, for instance.)

  - The rules which determine, for a given action being
    attempted by an entity with given attributes, against
    some other entities with given attributes, what the
    result is for a given setting of the "knobs"; where
    typical results are "allowed", "user prompted",
    "forbidden", "entity terminated", and so on.

Once the security model exists, users and system administrators
will have a clearer understanding of what knobs they can twiddle,
and what will happen when they do.  And I suspect that the Java
folks will discover that there are some things that need to be
added to the security model to make it complete and sensible.

The great advantage will be that consultants will then be able
to make reasoned and convincing presentations to principles,
telling them when it's safe to use Java, and how safe it is,
and why, rather than just saying "well, there are some known
problems, but it's really Hot, so I do/don't recommend it,
based on my gut feelings".

In the particular example you give, once it's been determined
that the applet was really written by Walmart, the security
system can then look in the security tables to see what
privileges applets written by Walmart and received from
server a.b.d.c should have.  Simple!  *8)

- -- -
David M. Chess                    /   Real nice Net you got here.
High Integrity Computing Lab      /     Be a pity if anything was to
IBM Watson Research               /        _happen_ to it...
Follow-Ups: